Continuous Deployment Transitions at Scale

Predictable, rapid, and data-driven feature rollout; lightning-fast; and automated fix deployment are some of the benefits most large software organizations worldwide are striving for. In the process, they are transitioning toward the use of continuous deployment practices. Continuous deployment enables companies to make hundreds or thousands of software changes to live computing infrastructure every day while maintaining service to millions of customers. Such ultra-fast changes create a new reality in software development. Over the past four years, the Continuous Deployment Summit, hosted at Facebook, Netflix, Google, and Twitter has been held. Representatives from companies like Cisco, Facebook, Google, IBM, Microsoft, Netflix, and Twitter have shared the triumphs and struggles of their transition to continuous deployment practices—each year the companies press on, getting ever faster. In this chapter, the authors share the common strategies and practices used by continuous deployment pioneers and adopted by newcomers as they transition and use continuous deployment practices at scale

Configuration Smells in Continuous Delivery Pipelines: A Linter and a Six-Month Study on GitLab

An effective and efficient application of Continuous Integration (CI) and Delivery (CD) requires software projects to follow certain principles and good practices. Configuring such a CI/CD pipeline is challenging and error-prone. Therefore, automated linters have been proposed to detect errors in the pipeline. While existing linters identify syntactic errors, detect security vulnerabilities or misuse of the features provided by build servers, they do not support developers that want to prevent common misconfigurations of a CD pipeline that potentially violate CD principles (“CD smells”). To this end, we propose CD-Linter, a semantic linter that can automatically identify four different smells in pipeline configuration files. We have evaluated our approach through a large-scale and long-term study that consists of (i) monitoring 145 issues (opened in as many open-source projects) over a period of 6 months, (ii) manually validating the detection precision and recall on a representative sample of issues, and (iii) assessing the magnitude of the observed smells on 5,312 open-source projects on GitLab. Our results show that CD smells are accepted and fixed by most of the developers and our linter achieves a precision of 87% and a recall of 94%. Those smells can be frequently observed in the wild, as 31% of projects with long configurations are affected by at least one smell

Detecting DoS Attacks on Notification Services

A notification service alerts a large number of recipients of important or emergency events in a timely manner. A Denial of Service (DoS) attack inserts unnecessary traffic to slow down or choke the notification service. A challenge of detecting DoS attacks lies in distinguishing them from temporary surges in normal traffic. This paper proposes an escalation hierarchy to detect DoS attacks by monitoring performance degradations at various levels. Our analysis shows the effectiveness of the approach. Further trials are underway

A Real-Time Extension to Logic Programming Based on the Concurrent Constraint Logic Programming Paradigm

Although concurrent logic programming languages provide a suitable implementation environment for real-time systems, they fail to give any notion of temporal correctness. We define a set of semantics whereby temporal constraints, consisting of delay, maximum execution time, and priority specifications can be implemented into existing concurrent logic programming languages. The notion of temporal inheritance is described which allows distribution of common temporal constraints to processes that are all part of the same task. We give some examples illustrating the utility of the language extension. 1 Introduction Real-time systems (RTS) can be defined as systems whose result not only depends on the correctness of the output, but also the time at which the output is produced. Hard RTSs have deadlines which if missed can be either disastrous (missile guidance systems) or useless (stock market prediction). Soft RTSs such as telephone exchanges, on the other hand can tolerate a certain prop..